Repository navigation
fix(pcap,pcapng): prefix capture-guard messages and name the block type in option guards - #2398
Merged
Merged
Conversation
…pe in option guards (#2300, #2301) #2300: the guards that reject a file's magic number or byte order had no PCAP:/PCAP-NG: prefix, unlike every other message in those modules, and PCAP's magic-number guard didn't say what it read. Four sites: schema/misc/pcap/header.py's magic_number_callback, misc/pcap/header.py's _make_magic (byte order unresolved/unknown), and two byte-order sites in schema/misc/pcapng.py that were the only two of nine messages in that file still missing PCAP-NG:. #2301: 128 PCAP-NG option guards in misc/pcapng.py ended in a full stop, unlike the house <prefix>: ... form (#2232, #2257), and the placement guard formatted self._type -- a plain int at make time, not the Enum_ BlockType it's cast to -- with bare {}, showing a raw number. A new _block_type_name() helper resolves either form through Enum_BlockType, idempotent for the enum case; applying the int form via .name directly would raise AttributeError, verified against pristine main. Also fixed: the if_tsresol/if_tzone option guards carried the identical full-stop defect, outside the issue's literal checklist but left would have made this consistency fix inconsistent with itself -- the file's full-stop count is now 0, which a new test asserts as an invariant. CHANGELOG.md regenerated (util/changelog_md.py) after correcting one docs/source/changelog/1.5.0.rst entry that quoted the old literal message. Tests: new tests/protocols/misc/test_capture_message_prefix_2300_2301_unit.py, 14 cases, 13 fail / 1 passes against pristine main (the one passing case is a characterisation pin of _type's runtime type, true on both trees).
JarryShaw
added
fix
Owner
Author
|
Review: GOOD TO GO at Three non-blocking notes from the review, worth a look but not required here:
|
JarryShaw
added
review: good-to-go
Contributor
|
Coverage: 91.68% (unit tier, Python 3.15,
Per-file detail: the |
JarryShaw
removed
the
review: good-to-go
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
make testpasses, and a test case covers the changeCHANGELOG.mdviautil/changelog_md.pyafter correcting the one 1.5.0 entry that quoted the old literal message.What is the purpose of your pull request?
fix — bug fixDescription
Closes #2300. Closes #2301.
PCAP:/PCAP-NG:prefix, unlike every other message in those modules. Four sites fixed:schema/misc/pcap/header.py'smagic_number_callback,misc/pcap/header.py's_make_magic(unresolved/unknown byte order), and the two byte-order sites inschema/misc/pcapng.pythat were the only two of nine messages in that file missingPCAP-NG:. PCAP's magic-number guard now also says what it read.<prefix>: …form (fix(ethernet,pcapng): reject a non-string MAC or EUI address (#2222) #2232/fix(arp): prefix the hardware-address messages and reject a bool with ProtocolError (#2256) #2257), and the placement guard formattedself._type— a plainintat make time, not theEnum_BlockTypeit's cast to — with bare{}, showing a raw number instead of the block type's name. Added a_block_type_name()helper resolving either form throughEnum_BlockType. Judgment call: the issue suggested.namedirectly; verified against pristineorigin/mainthat this raisesAttributeErroron the make path where_typeis a plainint, so the helper is necessary, not a stylistic choice.if_tsresol/if_tzoneoption guards carried the identical full-stop defect — leaving them would have made this consistency fix inconsistent with itself. The file's full-stop count is now 0, asserted as an invariant by the new test.docs/source/changelog/1.5.0.rstentry quoted the old literal error text (unknown byteorder magic); corrected and regeneratedCHANGELOG.mdfrom it, since 1.5.0 final is unreleased.tests/protocols/misc/test_capture_message_prefix_2300_2301_unit.py, 14 cases. Fail-without-fix: 13 failed / 1 passed against pristineorigin/main(the one pass is a characterisation pin of_type's runtime type, true on both trees).